Problem: The WS-Addressing standard assumes that the From and To fields are URLs of the Web Service requester and receiver. However, Web Services trading between two Activator endpoints typically use AS2-based routing ID’s (ZZHOME, ZZAWAY). Messages between Activator and third-party Web Service providers using WS-addressing may fail.
Solution: WS Addressing expects URL’s, not AS2 style routing ID’s: When Web Service addressing is expected to identify the sender, select the pickup option Address must be determined by either message attribute configuration or by protocol address only to determine From and To parties for each message. Depending on whether the partner's WS-Addressing is expecting a URL or a routing ID, you may need to add the expected URL as an alternate routing ID in the community and partner settings and set them as default, or use Collaboration settings to specify the desired ID to use when replying to that party.
Problem: Web Services addressing inter-operation with non
In the Activator WS-addressing header, From and To values use the default routing ID for the community and partner. These are normally AS2-like values, such as ZZCOMMUNITY, ZZPARTNER. However, non Activator Web Services endpoints create WS-Addressing headers that use From and To values that are the URL of the endpoints.
Solution: For inbound messages, enter the URLs sent by partner for From and To as default values, or use alternate routing IDs in the community and partner settings.
For outbound messages, either set the expected URL value as the default routing ID, or use collaboration settings to set the desired values. See Web Services collaboration settings.